Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000081_owner-urn-ietf _Fri Mar 28 14:59:00 1997.msg

Internet Message Format | 1997-04-01 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA04178
    for urn-ietf-out; Fri, 28 Mar 1997 14:59:00 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA04173
    for <[e-mail]>; Fri, 28 Mar 1997 14:58:57 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA17317  (mail destined for [e-mail]); Fri, 28 Mar 97 14:58:55 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
          by beach.w3.org (8.8.4/8.8.4) with SMTP
      id NAA14175; Fri, 28 Mar 1997 13:58:50 -0600
Message-Id: <[e-mail]>
Date: Fri, 28 Mar 1997 13:58:49 -0600
From: Dan Connolly <[e-mail]>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: Cecilia Preston <[e-mail]>
Cc: [e-mail]
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
References: <[e-mail]> <v03007801af619eac2549@[128.48.100.36]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

Cecilia Preston wrote:
> >> Example: URN:ISBN:0-395-36341-1
...
> >Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
> >make more sense.
> >
>
> You are imposing your hierarchical
>path name model into a space that is
> defined by community to have hyphens and had done so since the mid 1960's.
>
> Furthermore it is not up to the URN community to direct the use of that
> part of the space, that is up to the Namespace ID.  Please remember that
> this document is intended to illustrate how existing namespaces schemes can
> work within the URN syntax.

Hmm... I can see the social benefits of using the syntax
that the community is familiar with.

But do you see the technical benefits of exploiting the
URI hierarchy syntax? It allows the use of relative
URLs. It remains to be seen whether they would be used
in the ISBN context as much as they are in the http:
and ftp: contexts. But the technical benefit is there.

And it's not _my_ model -- it's the IETF standard model,
per RFC1808. (well... proposed standard). And I'm
not imposing it; I'm suggesting it.

If this working group has explicitly considered the costs
and benefits of both sides, and as a result, chosen
to go with the human-friendly syntax rather than the
syntax that exploits URL hierarchy, then I think that
deserves mention in the specification.

I suggest the following wording:

    NOTE: The ISBN space is hierarchical, and RFC1808
    (and RFC1630) might suggest that the '/' character
    be used to separate parts of the name. However,
    the value of doing so is not evident, and is believed
    to be significantly less than the value of using
    the '-' syntax that the community is familiar with.

    Using the '-' syntax, visual comparison of ISBN URNs
    with printed ISBN numbers is easier. And the '-' syntax
    facilitates copy-and-paste from extant ISBN numbers
    in ASCII, which generally use the '-' syntax.

I am being told that these issues have been debated at length
and resolved -- but I can't find the results in the relavent
documents. Let's get these arguments written down. That's the
way to stop blabber-mouths like myself from bringing them
up again and again!

The irony of the argument behind using '-' rather than '/'
is that it directly conflicts with the charter of this
working group:

===========
http://www.bunyip.com/research/ietf/urn-ietf/

Although the framework will allow URNs to
be defined that vary in terms of degree of scalability
and persistance, ensuring "user friendliness" of all resultant
identifiers is beyond the
scope of this group.
===========

I disagree with that part of the charter: the "user friendliness"
aspects of identifiers have a tangible impact on the reliability
of the network infrastructure and on the deployment of
these technologies. For that reason, they should be carefully
considered.

I suppose comments on the charter are somewhat out of order.
I apologize, and I will try to take them up in the right
venue. But I just wanted to write them down before I forget.

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21